Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.
Поддержка NVMe-oF для доступа к хранилищам появилась еще в VMware vSphere 7, а в обновлении Update 1 была улучшена и оптимизирована. В указанном выше документе рассматривается сравнение производительности традиционного протокола Fibre Channel Protocol (SCSI FCP) с реализацией FC-NVMe в vSphere 7.0 U1.
Для всех бенчмарков использовался тот же HBA-адаптер и инфраструктура сети хранения данных SAN. Для генерации нагрузки использовались утилиты fio (для создания разных по размеру операций ввода-вывода I/O, а также паттернов нагрузки) и Microsoft CDB (бенчмарк для генерации OLTP-нагрузки в SQL Server).
Результат оказался весьма интересным. С точки зрения IOPS протокол NVMe-oF смог выжать почти в два раза больше операций ввода-вывода практически для IO любого размера:
Задержка (Latency) также снизилась практически в два раза:
На картинке ниже приведены результаты теста Microsoft CDB для базы данных в числе транзакций в секунду:
Здесь также виден значительный прирост для NVMe-oF, а для двух виртуальных машин производительность выше почти в раза!
Остальные интересные детали тестирования - в документе.
Компания VMware пару недель назад объявила о выпуске бета-версии операционной системы Photon OS 4.0 Beta. Напомним, что эта ОС используется сейчас уже во всех виртуальных модулях VMware (Virtual Appliances), которые реализуют различные вспомогательные сервисы. Напомним, что о прошлой версии Photon OS 3.0 мы писали весной прошлого года вот тут.
Давайте посмотрим, что нового появилось среди возможностей обновленной ОС:
1. Ядро реального времени для приложений телекома и vRAN (Virtual Radio Network)
Наступает эра 5G, и VMware сделала в Photon OS 4.0 возможности поддержки телеком-приложений реального времени на уровне ядра (Photon Real Time kernel). Это позволит технологиям vRAN (Virtual Radio Network) использовать возможности ОС Photon при развитии инфраструктуры 5G-операторов.
2. Безопасность
Photon 4.0 получила поддержку таких технологий по обеспечению безопасности, как SELinux, Security Encrypted Virtualization – Encrypted Status и Intel Software Guard Extensions. Обязательная система контроля доступа, прошитая на уровне ядра, позволяет SELinux дать администраторам гранулярный и гибкий доступ к ресурсам. Также Photon OS позволяет из коробки, на уровне политик, обеспечить нужды приложений в изоляции. Также поддерживается SELinux для контейнеров, что было протестировано для docker, containerd и runc.
Поддержка драйверов Intel SGX drivers позволяет приложениям использовать ресурсы CPU для создания "анклавов" - полностью защищенных модулей исполнения, недоступных на аппаратном уровне другим процессам.
3. Оптимизации производительности для решения vSphere with Tanzu
Исторически Photon ОС имела специальный контекст ядра linux-esx, который был специальным образом оптимизирован для работе на платформе VMware ESXi точки зрения производительности и предоставляемых возможностей. В Photon 4.0 то же самое появилось и для контейнерной среды исполнения vSphere with Tanzu, например, уменьшение времени запуска для контейнеров и приложений.
4. Улучшения компонентов ОС
В Photon 4.0 были обновлены более 700 пакетов, включая ключевые компоненты, такие как tdnf, pmd, network config manager и многие другие. Также в релиз включены превью-фичи для, которые ожидаются в финальной версии ОС. Поэтому рекомендуется не использовать бету Photon 4.0 для производственных сред.
Разработка Photon OS очень сильно опирается на участие комьюнити. Поэтому ваши комментарии, предложения и отчеты об ошибках можно добавлять вот тут.
В этом релизе, как в прошлом, ОС распространяется в бинарном предзапакованном формате - загрузочный ISO, предустановленный минимальный OVA-пакет, кастомизированный под VMware, образ Amazon AMI, образ Google GCE, образ Azure VHD, а также образ Raspberry Pi (протестированный для архитектуры ARM64).
Образы Photon OS 4.0 Beta можно скачать по этой ссылке. Публичный репозиторий доступен вот тут.
Это такая утилита, построенная на принципах клеточного автомата (cellular automata, CA), которая позволяет смоделировать характеристики производительности для путей данных в кластере vSAN. Сам методика клеточных автоматов позволяет смоделировать и исследовать комплексную систему со множеством элементов, работающих параллельно и имеющих короткие соединения между собой, при этом создающих эмерждентную сущность.
При симуляции стека хранилищ данная утилита моделирует передачу блоков данных по сети через аппаратные ресурсы по различным коротким соединениям, таким как CPU->кэш->DRAM->SSD/HDD, соединения PCIe, Ethernet и т.п. Вот небольшое видео о том, как это работает:
Основная цель такой симуляции - получить идеальные показатели пиковой пропускной способности к хранилищам - так называемая speed-of-light (SOL) throughput.
При моделировании запросов ввода-вывода на чтение-запись применяются различные модели движения блоков данных по сети. Эти модели включают в себя функции репликации данных, вычисление parity, контрольных сумм, шифрование, компрессия данных и некоторые другие факторы, влияющие на длительность операций.
Результаты можно использовать для бенчмаркинга реальных инфраструктур, изменения настроек для повышения производительности, а также понимания затыков (bottlenecks), понижающих общую производительность стека работы с хранилищами vSAN в виртуальной инфраструктуре.
Вот пример такого моделирования:
В общем, если у вас есть время на подобные игры - скачивайте Storage Simulator Using Cellular Automata по этой ссылке. Инструкции по использованию доступны там же на вкладке "Instructions".
Пару недель назад на сайте проекта VMware Labs вышли обновления сразу нескольких утилит, поэтому вы, возможно, пропустили апдейты HCIBench 2.5 и 2.5.1. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.4 мы писали вот тут.
Давайте посмотрим, что нового появилось в версиях 2.5 и 2.5.1:
Добавлена возможность тестирования в рамках топологии vSAN HCI Mesh, теперь можно добавлять локальные и удаленные датасторы vSAN одновременно.
Добавлена поддержка локальных хранилищ, включая VMFS и тестирование vSAN-Direct.
Новый режим vSAN Debug Mode, который позволяет автоматически собрать бандлы vm-support и vmkstats при тестировании vSAN.
Изменена конвенция имен виртуальных машин на {vm_prefix}-{datastore_id}-batch_num-sequence_num.
Улучшенный формат отчета о тестировании.
Возможность указывать кастомные IP для тестовых машин.
Возможность выставлять CPU и память для тестовых машин.
Добавлено руководство по сетевому траблшутингу как раздел пользовательской документации.
Возможность обновления на текущую и последующие версии одной командой: tdnf install -y git && git clone https://github.com/cwei44/HCIBench.git && sh HCIBench/upgrade.sh
MD5 Checksum: 1d14426f92b353e90469a8623ade2bc1 HCIBench_2.5.1.ova
Исправлены ошибки с тестированием не-vSAN кластера, а также с превалидацией политики хранилищ.
Прочие исправления ошибок.
Скачать VMware HCIBench 2.5.1 можно по этой ссылке.
Некоторое время назад мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).
Устройства HCA могут коммуницировать с памятью приложений на сервере напрямую. Грубо говоря, если в обычном режиме (TCP) коммуникация по сети происходит так:
То при наличии на обоих хостах HCA, обмен данными будет происходить вот так:
Очевидно, что такая схема не только снижает нагрузку на CPU систем, но и существенно уменьшает задержки (latency) ввиду обхода некоторых компонентов, для прохождения которых данными требуется время.
Поддержка RDMA появилась еще в VMware vSphere 6.5, когда для сетевых адаптеров PCIe с поддержкой этой технологии появилась возможность обмениваться данными памяти для виртуальных машин напрямую через RDMA API. Эта возможность получила название Paravirtual RDMA (PVRDMA).
Работает она только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Метод коммуникации между виртуальными машинами в таком случае выбирается по следующему сценарию:
Если две машины общаются между собой на одном ESXi, то используется техника memory copy для PVRDMA, что не требует наличия HCA-карточки на хосте, но сама коммуникация между ВМ идет напрямую.
Если машины находятся на хостах с HCA-адаптерами, которые подключены как аплинки к VDS, то коммуникация идет через PVRDMA-канал, минуя обработку на CPU хостов, что существенно повышает быстродействие.
Если в коммуникации есть хоть одна ВМ на хосте, где поддержки RDMA на уровне HCA нет, то коммуникация идет через стандартный TCP-туннель.
Начиная с VMware vSphere 7 Update 1, для PVRDMA была добавлена поддержка оконечных устройств с поддержкой RDMA (Native Endpoints), в частности хранилищ. Это позволяет передать хранилищу основной поток управляющих команд и команд доступа к данным от виртуальных машин напрямую, минуя процессоры серверов и ядро операционной системы. К сожалению для таких коммуникаций пока не поддерживается vMotion, но работа в этом направлении идет.
Чтобы у вас работала технология PVRDMA для Native Endpoints:
ESXi должен поддерживать пространство имен PVRDMA. Это значит, что аппаратная платформа должна гарантировать, что физический сетевой ресурс для виртуальной машины может быть выделен с тем же публичным идентификатором, что и был для нее на другом хосте (например, она поменяла размещение за счет vMotion или холодной миграции). Для этого обработка идентификаторов происходит на сетевых карточках, чтобы не было конфликтов в сети.
Гостевая ОС должна поддерживать RDMA namespaces
на уровне ядра (Linux kernel 5.5 и более поздние).
Виртуальная машина должна иметь версию VM Hardware 18
или более позднюю.
За счет PVRDMA для Native Endpoints виртуальные машины могут быстрее налаживать коммуникацию с хранилищами и снижать задержки в сети, что положительно сказывается на производительности как отдельных приложений и виртуальных машин, так и на работе виртуального датацентра в целом.
На сайте проекта VMware Labs появилась очередная полезная штука - Storage Performance Tester. С помощью данного средства администраторы VMware vSphere могут в один клик проверить производительность хранилищ в плане IOPS, Latency и циклов CPU на одну операцию ввода-вывода для серверов VMware ESXi.
Эта утилита автоматизирует все шаги, которые необходимо предпринять для тестирования, включая развертывание виртуальных машин, запуск нагрузки по вводу-выводу, а также анализ производительности хранилища. Метрики, полученные в результате тестирования, визуализируются на графиках. Единственная вещь, которую вам нужно сделать - это выполнить соответствующую команду и ждать сгенерированного отчета о производительности хоста ESXi.
Средство создано как для администраторов платформы vSphere, так и для разработчиков, которым требуется решать проблемы производительности в виртуальной инфраструктуре. Также Storage Performance Tester удобно использовать для получения максимальных параметров производительности аппаратного обеспечения, а также программных компонентов (драйверы, настройки vSphere и vSAN).
Для запуска тестовой среды вам понадобятся:
python3
sshpass
2 ГБ свободного места
Linux-окружения (с версией ядра не менее 2.6.31)
Вот небольшое обзорное видео, где можно посмотреть всю процедуру запуска утилиты и, собственно, сам отчет с результатами тестирования:
Скачать Storage Performance Tester можно по этой ссылке.
Не так давно мы писали о том, что в последней версии VMware vSphere 7 Update 1 технология vMotion стала еще быстрее и теперь обеспечивает нужды горячей миграции даже для самых тяжелых виртуальных машин.
Напомним, что VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.
Интересны некоторые моменты. Например, в vSphere 6.7 используется технология отслеживания изменений CPU во время миграции stop-based trace, которая "подмораживает" все CPU, а в vSphere 7 U1 уже подмораживается только один процессор (техника loose page-trace Install):
Также vSphere 7.0 U1 передает compacted bitmap памяти вместо полного, что уменьшает время переключения на ВМ другого хоста:
Интересно уменьшение влияния миграции тяжелой БД Oracle на производительность - улучшение составило 19 раз!
Время миграции - до 50% меньше:
Ну и вообще в документе очень много всего интересного для интересующихся. Читайте здесь.
Многие из вас знакомы с одноплатной ARM-архитектурой компьютеров Raspberry Pi, которые позволяют модульно собирать очень крутые штуки для целей тестирования и обучения. Недавно компания VMware выкатила технологическое превью гипервизора ESXi для процессоров ARM (он же ESXi-Arm), которое доступно на сайте VMware Labs.
Конечно же, многие пользователи бросились устанавливать его на компьютеры Raspberry Pi, которые в большом количестве есть у энтузиастов. Оказалось, что поставить туда ESXi весьма простая задача, особенно, если речь идет о Raspberry Pi 4.
2x USB drive (один для записи гипервизора, а второй как installation media)
Кабель USB-C (питание)
Micro HDMI для монитора
Сначала лучше прочитать официальный гайд по продукту, который есть на странице ESXi-Arm сайта VMware Labs. Для старых модификаций Raspberry Pi могут быть нюансы, но с новыми для Windows порядок примерно такой:
Копируем содержимое загрузочной директории на SD-карту
Копируем содержимое архива RPi4_UEFI_Firmware_v1.20.zip с перезаписью поверх существующего содержимого на SD-карту
Если у вас Raspberry Pi на 4 ГБ, открывайте config.txt и добавляйте следующую строчку в конец файла без пробелов: gpu_mem=16
Настраиваем UEFI:
Вставляем SD-карту в Raspberry Pi
Подключаем USB-клавиатуру и монитор по HDMI
Подключаем питание через USB-C
Нажимаем ESC до того, как покажется UEFI menu
Идем в раздел:
Device Manager > Raspberry Pi Configuration > Advanced Configuration
Подсвечиваем опцию Limit RAM to 3GB
Нажимаем Enter и стрелками на клавиатуре выставляем значение DISABLED
По F10 сохраняем конфигурацию
Нажимаем ESC, чтобы выйти на домашнюю страницу
Идем к Continue и нажимаем Enter
Тепреь загружаем установочный образ VMware-VMvisor-Installer-7.0.0-16966451.aarch64.iso по этой ссылке.
Теперь из ISO-образа с помощью UNetbootin надо создать загрузочную флешку:
Далее:
Вставляем установщик на USB-флешке в Raspberry Pi
Нажимаем ESC до того, как покажется UEFI menu
Выбираем USB-флешку первой в порядке загрузки
После начала загрузки ESXi:
Быстро нажимаем SHIFT+O (это буква)
Внизу экрана вбиваем autoPartitionOSDataSize=8192 (это ограничит установку ESXi 8 ГБ, остальное пространство можно будет отдать под датастор для виртуальных машин)
При установке ESXi убедитесь, что указано корректное устройство для установки гипервизора
Вставляем сетевой кабель и убираем флешку
Далее после включения нужно опять пойти в Boot Maintenance Manager > Boot Options > Change Boot Order и выбрать там флешку, куда вы установили ESXi:
После этого ваш ESXi загрузится и получит IP-адрес от DHCP, который лучше заменить на статический. После этого вы можете соединиться с хостом через веб-интерфейс и увидеть, что для остатков пространства на флешке был создан датастор для виртуальных машин.
На сайте проекта VMware Labs вышла очередная новая утилита - vSphere Pod Autoscaler, предназначенная для пользователей vSphere PodVM, которые хотят настроить автомасштабирование узлов PodVMs на базе использования ими памяти.
В начале октября этого года прошла конференция VMworld 2020, которую компания VMware впервые провела исключительно в онлайн-формате. Там было сделано много интересных анонсов, главные из которых - это развитие экосистемы поддержки контейнеризованных приложений и расширение продуктовой линейки для автоматизации облачных инфраструктур.
Сегодня мы поговорим о второй части - решении VMware vRealize AI Cloud, которое предназначено для автоматического повышения эффективности использования хранилищ в рамках концепции самооптимизирующегося датацентра.
Эту концепцию вендоры различных ИТ-платформ продвигают уже давно. Ее суть заключается в том, что решения в рамках датацентра будущего (как программные, так и аппаратные) должны самостоятельно отслеживать изменяющиеся метрики среды, в которой они работают, после чего автоматически вносить коррективы в конфигурации для максимально эффективного функционирования инфраструктуры в целом.
Еще одним трендом VMware считает развитие гибридных инфраструктур, которые будут строить крупные компании. В гибридной среде важна унификация процедур управления и технических инструментов, над чем VMware работает уже давно (например, в этой парадигме построено решение Cloud Director 10.2).
Так вот, в гибридной среде у каждого онпремизного решения должны быть его облачные аналоги, но должны быть и чисто облачные инструменты, которые как раз делают датацентр самооптимизирующимся, поскольку за это отвечает вендор платформы. Одним из таких инструментов и стало решение vRealize AI Cloud:
vRealize AI Cloud поставляется вместе с решением vRealize Operations Cloud в рамках подписки vRealize Cloud Universal. За счет использования алгоритмов машинного обучения этот продукт позволяет адаптироваться к изменяющимся условиям в характере нагрузок и проводить постоянную оптимизацию использования хранилищ (а именно улучшая конкретные KPI, вроде пропускной способности или latency).
Сейчас эта технология работает только с хранилищами vSAN, но потенциально нет никаких препятствий для VMware открыть ее и для других облачных хранилищ.
Как видно из картинки выше, vRealize AI Cloud генерирует и применяет настройки для оптимизации работы с хранилищами, а также дает администратору инструменты для отслеживания производимых изменений и средства мониторинга измеренных количественных улучшений.
Консоль vRealize AI Cloud предлагает администратору решения 4 блоков задач:
Оптимизация производительности в кластере
Оптимизация емкости хранилищ
Решение проблем разного характера, в зависимости от типа объекта
Анализ конфигураций объектов и управление ими
Если перейти на уровень виртуальных датацентров, администратор видит те из них, где оптимизация кластеров уже включена (зелено-синий цвет), и те, где выключена, причем для обоих вариантов показано, на сколько процентов можно улучшить количественные метрики:
Можно провалиться на уровень кластера (выбрав соответствующую точку в периметре) и увидеть определенные хосты ESXi, где могут быть проведены оптимизации:
В частности мы видим в реальном времени поток оптимизаций (верхняя строчка), а также основные параметры производительности справа - latency и пропускную способность:
Раскрыв уровень оптимизаций, можно увидеть, какие конкретно настройки и в какое время были изменены. В данном случае был уменьшен размер кэша, поскольку AI Cloud предположил, что это улучшит write latency на 25%:
Конечно же, предположения могут не оправдаться, и тогда AI Cloud откатит настройку, чтобы убедиться, что хуже KPI не стали.
В потоке действий AI Cloud мы четко видим таймлайн изменений и детальные графики производительности на уровне каждого из выбранных хостов:
Если AI Cloud не включен в кластере, то будет рассчитан примерный потенциал оптимизаций, который, на самом деле, представляет собой довольно серьезные цифры, поэтому вполне имеет смысл хотя бы включить и попробовать AI Cloud в деле:
Когда вы включаете этот движок, вы можете выбрать степень агрессивности работы алгоритма оптимизаций:
Консервативный режим всегда оставляет запас по производительности и емкости при выполнении рекомендаций по оптимизации, а агрессивный - действует весьма смело. Как всегда, начинать нужно с консервативного режима и потом потихоньку увеличивать степень. После включения механизма AI Cloud начнется процесс обучения системы паттернам нагрузок, только после чего уже начнется генерация и применение рекомендаций.
В среднем, по тестам VMware, оптимизации хранилищ vSAN могут достигать 60% за счет использования движка AI Cloud. Например, по тестам Rackspace в 4-узловом кластере хранилищ улучшения полосы пропускания на запись (write-throughpu) составили 18%, а уменьшение задержек находилось на уровне 40%-84%.
Также AI Cloud тесно интегрирован с политиками хранилищ SPBM (Storage Policy Based Management). Настройки этих политик также влияют на производительность - например, можно отключить дедупликацию, и это существенно улучшит производительность хоста за счет уменьшения нагрузки на CPU и хранилища:
В целом, решение vRealize AI Cloud - это шаг вперед в реализации концепции самооптимизирующихся датацентров в разрезе хранилищ. Будем надеяться, что решение уже скоро будет доступно в облачных инфраструктурах сервис-провайдеров VMware Cloud.
Также на конференции VMworld Online 2020 компания VMware показала, как именно будет выглядеть решение vRealize AI Cloud:
Недавно компания VMware объявила о доступности для загрузки новой версии фреймворка для управления виртуальной инфраструктурой с помощью сценариев PowerCLI 12.1. Напомним, что о прошлой мажорной версии PowerCLI 12, вышедшей в апреле этого года, мы писали вот тут.
Давайте посмотрим, что нового появилось в PowerCLI 12.1:
Несколько новых командлетов было добавлено в модуль VMware.VimAutomation.WorkloadManagement
Get-WMCluster
Set-WMCluster
Enable-WMCluster
Disable-WMCluster
Несколько новых командлетов для vSphere Lifecycle Manager (vLCM) было добавлено в модуль VMware.VimAutomation.Core (подробнее тут)
Get-LcmImage
Test-LcmClusterCompliance
Test-LcmClusterHealth
Вот пример работы Get-LcmImage:
В модуле VMware.VimAutomation.Core было сделано несколько улучшений, включая новые параметры для командлетов New-Cluster и Set-Cluster, а также New-ContentLibraryItem и Set-ContentLibraryItem. Также были несколько обновлены параметры командлетов New-VM/Set-VM, New-Datastore, New-HardDisk и Get-NetworkAdapter/Get-VirtualNetwork
Несколько новых командлетов было добавлено в модуль VMware.VimAutomation.Vmc:
Добавлен параметр Cluster в командлеты Add-VmcSddcHost и Remove-VmcSddcHost
Свойства VCenterHostName и VCenterCredentials добавлены объекту SDDC
В модуле VMware.VimAutomation.Storage появилось несколько новых командлетов для управления безопасной очисткой дисков vSAN, томами Cloud Native Storage и контейнерами VVols:
Start-VsanWipeVsanDisk
Get-VsanWipeDiskState
Stop-VsanWipeVsanDisk
Get/New/Set/Remove-CnsVolume
New-CnsContainerCluster
New-CnsKubernetesEntityReference
New-CnsKubernetesEntityMetadata
New-CnsVolumeMetadata
Add-CnsAttachment
Remove-CnsAttachment
Get-VvolStorageContainer
Улучшения модуля VMware.VimAutomation.Storage:
Командлеты Set-VsanClusterConfiguration и Get-VsanClusterConfiguration теперь поддерживают режимы "vSAN compression only mode" и "vSAN enforce capacity reservation"
Get-VsanSpaceUsage более гранулярно показывает статистику свободного пространства
Командлеты Get-VasaStorageArray и Get-VasaProvider теперь могут фильтровать VASA providers по контейнерам VVols
Моуль VMware.VimAutomation.Security был существенно обновлен:
Добавлен командлет Get-TrustedClusterAppliedStatus для получения примененного статуса доверенных сервисов в доверенных кластерах
Добавлен командлет Set-TrustedCluster для ремедиации кластера в состоянии "not healthy"
После установки у вас появится утилита vcfkite, которая позволит управлять инфраструктурой VCF через SDDC Manager. Она является кроссплатформенной и протестирована на Linux CentOS и Windows 2012.
Сама утилита это wheel-пакет, который можно развернуть с помощью нативной команды pip3:
Основное назначение данного средства - дать пользователям удобный инструмент для управления VMware Cloud Foundation API с помощью простого языка Python.
Для начала работы вам понадобится Python версии 3.6 или более поздней, а также VCF 4.0.1 или более поздняя.
Скачать Python Utility for VMware Cloud Foundation Management можно по этой ссылке.
Многие из вас знают, что компания VMware с каждым новым релизом мажорной версии платформы vSphere улучшает техники горячей миграции виртуальных машин vMotion. Последнее обновление VMware vSphere 7 Update 1 - не исключение, там было сделано много для того, чтобы технология vMotion работала еще быстрее и обеспечивала нужды горячей миграции даже для самых тяжелых виртуальных машин.
Ранее vMotion могла не пройти для больших ВМ, которые имели более 64 vCPU и 512 ГБ памяти (они же Monster VMs). В документе "vMotion Innovations in vSphere 7.0 U1" можно найти конкретное описание улучшений. Давайте посмотрим на них вкратце.
Прежде всего, VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.
В документе выше для примера делается миграция vMotion сервера БД Oracle, запущенного в виртуальной машине с 72-vCPU / 1 TБ памяти на борту. На картинке ниже показано число тразакций в секунду с шагом как раз в секунду - до, во время и после vMotion (тест HammerDB):
Основные выводы теста, проведенного для такой нагрузки:
Общее время миграции уменьшилось более чем в 2 раза (с 271 секунды до 120 секунд)
Итоговое время для установления трассировки уменьшилось с 86 секунд до 7.5 секунд (снизилось в 11 раз)
Общее проседание пропускной способности во время миграции - на 50% для vSphere 6.7 и всего лишь 5% для vSphere 7.0 Update 1
Ответ Oracle во время переключения в среднем стал менее одной секунды, а ранее составлял более 6 секунд
Второй тест проводили для миграции vMotion сервера БД Oracle в виртуальной машине с 12 vCPU / 64 ГБ памяти для vSphere 6.7 и vSphere 7.0 U1. На картинке ниже показано число транзакций в секунду с шагом в полсекунды - до, во время и после vMotion (тест HammerDB):
Основные результаты теста:
Общее время горячей миграции сократилось с 23 секунд в vSphere 6.7 до 11 секунд в vSphere 7.0 U1 (уменьшение в 2 раза)
Итоговое время для установления трассировки уменьшилось с 2.8 секунд до 0.4 секунд (снизилось в 7 раз)
Увеличение полосы пропускания где-то на 45% (около 3480 транзакций в секунду, по сравнению с 2403 транзакции в секунду)
На сайте проекта VMware Labs вышла очередная полезность - сценарий для интеграции VMware vRealize Network Insight (vRNI) и VMware HCX. Напомним, что vRNI - это решение для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений, а HCX - продукт для миграций с различных опремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud.
С помощью данного скрипта администраторы VMware vSphere могут упростить и ускорить процесс миграции виртуальных машин. Сначала сценарий за счет vRNI обнаруживает приложение и его границы использования сети и ресурсов в рамках виртуальной машины, после чего создает под него структуры внутри самого vRNI.
Затем эти vRNI application constructs интегрируются в объекты HCX Mobility Groups, экономя время на ручное создание этих сущностей. После подготовки объектов вы можете начать сам процесс миграции виртуальных машин.
Для работы сценария оба продукта vRNI и HCX должны иметь лицензию Enterprise, также у вас должны быть установлены модули PowervRNI and the PowerCLI HCX.
Пример использования сценария:
$vrni_pw = ConvertTo-SecureString 'admin' -AsPlainText -Force
$hcx_pw = ConvertTo-SecureString 'VMware1!' -AsPlainText -Force
./sync-vrni-to-hcx.ps1 -vRNI_Server 10.196.164.134 -vRNI_Username admin@local -vRNI_Password $vrni_pw -HCX_Server hcxe.vrni.cmbu.local -HCX_Username hcx@cmbu.local -HCX_Password $hcx_pw -HCX_DestinationVC vc-pks.vrni.cmbu.local -HCX_DestinationCloud hcxc.vrni.cmbu.local
[03-05-2020_05:19:59] Connecting to vRealize Network Insight..
[03-05-2020_05:20:01] Retrieving all applications..
[03-05-2020_05:20:20] Found application: 'onprem_imagic' with 6 VMs
[03-05-2020_05:20:22] Found application: '3TierApp02' with 1 VMs
[03-05-2020_05:20:25] Found application: 'HIVE Training' with 1 VMs
[03-05-2020_05:20:27] Found application: 'VDI Pool 1' with 8 VMs
[03-05-2020_05:20:29] Found application: 'app_mcclanahanc' with 2 VMs
[03-05-2020_05:20:31] Found application: 'Top-Video' with 15 VMs
[03-05-2020_05:20:33] Found application: 'F5-3TierApp05' with 5 VMs
[03-05-2020_05:20:34] Connecting to VMware HCX..
[03-05-2020_05:20:48] Created Mobility Group: 'onprem_imagic_2020-03-05'
[03-05-2020_05:20:49] Created Mobility Group: '3TierApp02_2020-03-05'
[03-05-2020_05:20:50] Created Mobility Group: 'HIVE Training_2020-03-05'
[03-05-2020_05:20:51] Created Mobility Group: 'VDI Pool 1_2020-03-05'
[03-05-2020_05:20:52] Created Mobility Group: 'app_mcclanahanc_2020-03-05'
[03-05-2020_05:20:53] Created Mobility Group: 'Top-Video_2020-03-05'
[03-05-2020_05:20:54] Created Mobility Group: 'F5-3TierApp05_2020-03-05'
Коллега с virten.net написал замечательную статью об использовании сетевых адаптеров USB на хостах VMware ESXi, основные моменты которой мы приведем ниже.
Напомним, что подключить сетевые адаптеры USB на хостах ESXi можно с помощью драйвера USB Network Native Driver for ESXi, о котором мы не так давно писали вот тут. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.
Еще один вариант использования таких адаптеров - когда у вас (например, на тестовом сервере) есть всего один гигабитный порт, а вам нужно тестировать технологии и продукты, где нужно несколько высокоскоростных соединений.
Итак, после того, как вы скачаете драйвер, его установка делается одной командой:
С помощью PowerShell можно создать кастомизированный образ ESXi с уже вшитым драйвером сетевого USB-адаптера. Просто раскомментируйте строчку с нужной версией драйвера:
# ESXi 7.0 Image with USB NIC Fling 1.6:
$baseProfile = "ESXi-7.0.0-15843807-standard" # See https://www.virten.net/vmware/vmware-esxi-image-profiles/ for available Image Profiles
$usbFling = "ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip" # Uncomment for ESXi 7.0
#$usbFling = "ESXi670-VMKUSB-NIC-FLING-39203948-offline_bundle-16780994.zip" # Uncomment for ESXi 6.7
#$usbFling = "ESXi650-VMKUSB-NIC-FLING-39176435-offline_bundle-16775917.zip" # Uncomment for ESXi 6.5
При установке VMware ESXi на хост, где есть только USB сетевые адаптеры, процесс может зависнуть на 81%. В этом случае почитайте вот эту статью.
Кстати, ваши USB-адаптеры лучше всего пометить наклейками. Автор предлагает указать имя хоста ESXi, MAC-адрес адаптера и его номер vusbX:
Номер виртуального vusbX не сохраняется при перезагрузках. Начиная с версии драйвера 1.6 можно закрепить MAC-адрес за нужным vusbX. Сначала найдем наш адаптер:
# esxcli network nic list |grep vusb |awk '{print $1, $8}'
vusb0 00:23:54:8c:43:45
vusb1 a0:ce:c8:cd:3d:5d
Затем сделаем статический маппинг адаптеров с использованием модуля vmkusb_nic_fling:
# esxcli system module parameters set -p "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d" -m vmkusb_nic_fling
В данной команде нужно перечислить все адаптеры через пробел (если вы вызываете ее второй раз, то нужно переуказать каждый из адаптеров, иначе маппинг сбросится).
Далее нужно проверить маппинги с помощью команды:
# esxcli system module parameters list -m vmkusb_nic_fling
Name Type Value Description
-------------------------- ------ ----------------- -----------
usbCdromPassthroughEnabled int Enable USB CDROM device for USB passtrough: 0 No, 1 Yes
vusb0_mac string 00:23:54:8c:43:45 persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac string a0:ce:c8:cd:3d:5d persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac string persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac string persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac string persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac string persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac string persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac string persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx
Если вы хотите сделать текущий маппинг постоянным, то используйте команду:
# esxcli system module parameters set -p "$(esxcli network nic list |grep vusb |awk '{print $1 "_mac=" $8}' | awk 1 ORS=' ')" -m vmkusb_nic_fling
Также статические маппинги можно сделать и через PowerCLI. Выводим адаптеры:
PS> Get-VMHostNetworkAdapter -VMHost esx2.virten.lab -Physical -Name vusb* |select Name,Mac
Name Mac
---- ---
vusb0 00:23:54:8c:43:45
vusb1 a0:ce:c8:cd:3d:5d
Далее проводим операцию vMotion виртуальной машины между хостами ESXi. Результат таков:
Очевидно, кросс-соединение на адаптерах 2.5G рулит.
Проверка совместимости
Не все сетевые адаптеры USB поддерживаются нативным драйвером. Их актуальный список всегда можно найти вот тут. Вот эти адаптеры точно работают:
Адаптеры доступны в форм-факторах USB-A и USB-C. Между ними есть переходники.
Если вам нужно высокоскоростное соединение (multi-gigabit) между несколькими хостами, можно посмотреть на следующие коммутаторы:
MikroTik CRS305-1G-4S+IN ($130 USD) - 4 порта
MikroTik CRS309-1G-8S+IN ($260 USD) - 8 портов
Netgear MS510TX ($260 USD) - 10 портов
TRENDnet TEG-30102WS ($450 USD) - 10 портов
Самое быстрое и дешевое соединение между двумя хостами ESXi - соединить адаптеры патч-кордом напрямую:
Проверяйте параметр MTU size, когда включаете Jumbo Frames
Если вы меняете размер MTU на виртуальном коммутаторе, он принудительно меняется на всех подключенных к нему физических сетевых адаптерах. Имейте в виду, что эти адаптеры должны поддерживать выставляемый MTU size.
Посмотреть размер MTU можно следующей командой:
[root@esx4:~] esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 0000:00:1f.6 ne1000 Up 1000Mbps Full 00:1f:c6:9c:47:13 1500 Intel Corporation Ethernet Connection (2) I219-LM
vusb0 Pseudo uether Up 1000Mbps Full 00:24:9b:1a:bd:18 1600 ASIX Elec. Corp. AX88179
vusb1 Pseudo uether Up 1000Mbps Full 00:24:9b:1a:bd:19 1500 ASIX Elec. Corp. AX88179
В данном примере MTU size настроен как 1600, что подходит для адаптеров (и работает для сети NSX-T). Если же вы поставите его в 9000, то увидите в vmkernel.log ошибки для dvSwitch о том, что такой размер не поддерживается устройством:
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: vmkusb: Set MTU 9000 is not supported: Failure
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: Uplink: 16632: Failed to set MTU to 9000 on vusb0
Если вы хотите проверить корректность вашего MTU size, то можно использовать команду ping с размером пакета MTU-28 байт (8 байт на заголовок ICMP и 20 байт на заголовок IP). Таким образом, для MTU size 1600 используйте число 1572:
[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1572 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1572 data bytes
1580 bytes from 192.168.225.10: icmp_seq=0 ttl=64 time=0.680 ms
[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1573 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1573 data bytes
sendto() failed (Message too long)
Производительность дисковой подсистемы в Linux зависит от различных параметров и настроек, одной из которых является тип планировщика для работы с потоком ввода-вывода (I/O scheduler). Если вы планируете использовать продукт StarWind VSAN for vSphere для создания программных хранилищ на базе виртуальных машин Linux (Virtual Storage Appliance), то информация ниже может быть вам полезна.
В зависимости от типа целевого хранилища, иногда целесообразно поменять используемый тип планировщика. Чтобы вывести текущий тип I/O scheduler, нужно выполнить следующую команду для выбранного устройства:
В данном случае мы видим, что тип планировщика - это noop (он же none). В зависимости от версии ядра Linux, он также может быть выставлен как mq-deadline. Кстати, обратите внимание, что тип планировщика указывается на уровне отдельного дискового устройства.
Считается, что для SSD и NVMe-устройств лучше ставить планировщик none / noop, который уменьшает нагрузку на CPU, а вот для HDD-дисков лучше использовать mq-deadline, который показывает лучшие результаты по итогам синтетических тестов.
Чтобы поменять планировщик на noop для диска sdb, нужно выполнить следующую команду:
# echo noop > /sys/block/sdb/queue/scheduler
Потом надо обязательно проверить, что планировщик поменялся, следующей командой:
Но это все меняет тип планировщика на время, до перезагрузки, чтобы вы могли проверить разные планировщики и сделать тесты производительности. Чтобы сохранить эти изменения, нужно изменить файл scheduler.rules в директории /etc/udev/rules.d/
Например, если вы хотите поменять планировщик на noop для устройства sdb и установить политику "no read ahead" для него, то нужно добавить туда следующую строчку:
Рекомендуется выставлять одинаковый тип планировщика на всех узлах, где расположены хранилища StarWind VSAN. Также надо отметить, что последние версии продукта StarWind VSAN for vSphere при установке автоматически выставляют тип планировщика noop для SSD-хранилищ.
Напомним, что Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте.
Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM. Платформа VMware vSphere 6.7 EP10 и более поздние версии поддерживают память Intel Optane persistent memory 100 series (она же Intel Optane PMem) со вторым поколением процессоров Intel Xeon Scalable в режимах App Direct и Memory.
В указанном документе рассматривается производительность данной памяти в новом режиме Balanced Profile для конфигурации BIOS, который впервые появился в процессорах Intel этой серии в целях повышения производительности. За счет данного режима производительность памяти увеличилась в 1.75 раза, как показано на картинке по результатам тестов:
Раньше DRS был сфокусирован на выравнивании нагрузки на уровне всего кластера хостов ESXi в целом (на базе расчета стандартного отклонения по производительности), то есть бралась в расчет загрузка аппаратных ресурсов каждого из серверов ESXi, на основании которой рассчитывались рекомендации по миграциям vMotion виртуальных машин. Теперь же механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness), отражающий удовлетворение потребности виртуальной машины в свободных ресурсах.
Пример 1 - хост с отклонением нагрузки от большинства
В старом DRS, работающем по принципу выравнивания нагрузки в кластере на базе анализа стандартного отклонения загруженности хостов в рамках определенного порога, могла возникнуть вот такая ситуация, когда DRS не требовалось предпринимать никаких действий по выравниванию нагрузки, хотя они, очевидно, требовались:
Новый DRS работает на базе анализа ресурсов для каждой виртуальной машины и будет перемещать их средствами vMotion, пока не достигнет максимальной доступности ресурсов для каждой ВМ. В точно таком же случае, как описано выше, это приведет в итоге к более сбалансированной ситуации:
Пример 2 - неравномерная загрузка хостов в кластере
В старом DRS был порог по дисбалансу в кластере, и если он не превышен - то механизм балансировки не запускался. Это могло приводить к образованием групп хостов с разными уровнями средней загрузки процессора и памяти:
В ситуации с новым DRS ситуация в итоге, опять-таки, получается более справедливая:
Также полезной оказывается метрика DRS Score (она же VM Hapiness), которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness.
Если все машины чувствуют себя "комфортно" на всех хостах, то DRS Score оказывается максимальным:
Если подать нагрузку на пару хостов ESXi, то их средний DRS Score падает, а на дэшборде указывается число машин, для которых рассчитаны низкие уровни DRS Score:
После того, как DRS обработает эту ситуацию, нагрузка на хосты выравнивается, а значение DRS Score увеличивается:
На днях компания VMware выпустила обновления сразу трех интересных утилит для виртуальной инфраструктуры на сайте проекта VMware Labs. Давайте посмотрим, что там интересного.
Оно позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать.
Из нового:
Можно получить версию App Volumes через API с возможностью получения номера билда
Версия App Volumes 2006 и более поздняя имела проблему с Entitlement Sync 4.0 при возвращении строкового значения
Скачать App Volumes Entitlement Sync 4.1 можно по этой ссылке. Напомним, что про предыдущую версию Entitlement Sync 4.0 мы рассказывали вот тут.
Напомним, что это средство позволяет отобразить сложное множество программных интерфейсов VMware vRealize Automation Cloud API в простой набор функций PowerShell.
Что появилось нового:
4 новых командлета для VMC (VMware Cloud)
5 новых командлетов для AWS
Поддержка Powershell 7 on Windows
Исправления ошибок
Скачать Power vRA Cloud 1.3 можно по этой ссылке. О возможностях версии 1.1 можно почитать у нас вот тут.
Некоторые из вас знают, что есть такое решение VMware vRealize Network Insight (vRNI), которое предназначено для мониторинга и защиты сетевой инфраструктуры виртуальной среды VMware vSphere.
Администраторам виртуальной инфраструктуры часто приходится делать копии различных ее управляющих компонентов, в том числе vRNI. Сейчас VMware рекомендует делать резервную копию конфигурации vRNI на уровне всей виртуальной машины (см. KB 55829). Рекомендуется выключить ВМ с vRNI, скопировать ее целиком, а потом включить снова - это единственный поддерживаемый способ на данный момент.
Martijn Smit опубликовал интересный пост о том, что на самом деле у vRNI есть способ резервного копирования и восстановления конфигурации через API, для которого есть специальный API endpoint по пути /settings/backup:
Если посмотреть внутрь, то там можно увидеть вполне работоспособный механизм бэкапа конфигурации vRNI:
Используя API endpoint /api/ni/settings/backup,вы можете создать резервную копию конфигурации vRNI и перенаправить ее по SSH или FTP на бэкап-сервер в виде tar-файла со следующим содержимым:
Большинство этих файлов человекочитаемы, если вы откроете их в текстовом редакторе. Там находятся копии настроек приложений, объектов pinboards, data sources, сохраненный поиск, системные настройки (Syslog, SMTP и т.п.), пользовательские конфигурации и многое другое.
Для работы с конфигурациями vRNI через API Martijn сделал модуль PowervRNI. Вот пример использования сценария резервного копирования:
На сайте проекта VMware Labs обновилась утилита Horizon Reach до версии 1.1, которая позволяет проводить мониторинг и алертинг для развертываний VMware Horizon на площадках заказчиков (только в реальном времени, без исторических данных). Horizon Reach предназначен для тех окружений VMware Horizon, которые образуются в крупных компаниях на уровне площадок (Pod) в рамках концепции Cloud Pod Architecture как отдельный домен отказа (либо где площадки изолированы, но хочется иметь доступ к мониторингу в моменте из одной точки).
Это большое обновление, и в нем появилось много новых возможностей и исправлений ошибок прошлой версии (о которой мы писали осенью прошлого года вот тут).
Давайте посмотрим, что нового в Horizon Reach 1.1:
Теперь утилитой можно напрямую мониторить компоненты Unified Access Gateways, также доступны функции скачивания конфигурации и логов
Пользовательские сессии можно просматривать в рамках следующих представлений:
Pools
Farms
Unified Access Gateways
Global Entitlements
Global Application Entitlements
Алармы были полностью переработаны, чтобы поддерживать отправку нотификаций в следующие каналы:
SMTP
Slack
Сторонние средства через сценарии PowerShell
LDAP-интеграция алармов поддерживает кириллицу
Улучшенный дэшборд алармов
Обновления vCenter:
Хосты теперь видимы, и для них отслеживается производительность
Датасторы теперь видимы, показано свободное пространство
Кастеры теперь видимы, для них доступны различные представления - пулы, фермы и т.п. Также можно использовать интеграцию PowerShell и API
Профили vGPU теперь показаны в представлении пулов
Множество исправлений ошибок
Скачать VMware Horizon Reach 1.1 можно по этой ссылке.
Некоторые функции vCloud Director (VCD) по работе с виртуальными машинами по-прежнему недоступны через стандартные командлеты PowerCLI, поэтому к ним необходимо обращаться через VCD API.
Jon Waite в своем блоге опубликовал PowerCLI-сценарий, с помощью которого можно обратиться к VCD API и увеличить размер загрузочного диска ВМ. Надо сказать, что при подобного рода манипуляциях (как увеличение, так и уменьшение диска) всегда есть риск потери данных, поэтому обязательно сделайте резервную копию.
Стандартное определение функции - на входе объект виртуальная машина и новый желаемый размер первого (загрузочного) диска в МБ.
7-9
Одна команда, разделенная на 3 строчки. Вызов VCD API для определения поддерживаемых версий API, чтобы не хардкодить конкретную версию в скрипте.
10-12
Обрабатывает результат прошлой строчки, определяет последнюю актуальную версию VCD API и сохраняет $APIVersion для использования позднее.
14
Определяет SessionId для текущей сессии PowerCLI (Connect-CIServer), чтобы использовать API-запросы на строчках 17 и 27.
15
Получает хэш $Headers для отправки API-запросов (переменные SessionId и APIVersion были получены ранее).
16
Определяет API URI через поддерживаемый VM HTTP reference.
17
Получает представление XML секций virtualHardwareSection/disks определенной ВМ.
19-20
Находит первый диск, привязанный к ВМ (ResourceType 17 = Hard Disk)
22-23
Обновляет размер диска ВМ на базе входного параметра емкости у функции. На самом деле у VCD достаточно обновить capacity, а VirtualQuantity обновляем для консистентности (в байтах).
24
Добавляем дополнительное значение к $Header, чтобы обозначить Content-Type, который мы отправляем обратно к API.
26-34
Попытки обновить API измененным XML, включая новый размер диска и возвращаем ошибку с описанием, если операция прошла неудачно.
После выполнения сценария нужно будет, само собой, расширить соответствующий раздел гостевой системы. Современные версии Windows и Linux могут раскатывать существующий раздел на весь размер физического устройства даже без перезагрузки машины.
Пример использования сценария:
PS /> $VM = Get-CIVM -Name 'TestVM01'
PS /> $VM | Update-CIVMBootDisk -NewSizeMB 2048
Disk resize for VM TestVM01 submitted successfully.
На сайте проекта VMware Labs вышло очередное полезное обновление - утилита HCIBench версии 2.4. О прошлых версиях HCIBench мы писали тут и тут. Напомним, что она позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.
Суть работы HCIbench проста - пользователь задает параметры работы скрипта, а утилита дает команду Vdbench, какие действия необходимо выполнить в кластере хранилищ.
Посмотрим, что нового в HCIBench 2.4:
Исправлена частая ошибка при указании хоста во время развертывания
Поддержка варианта запуска easy run для "растянутого" (stretched) кластера
Исправлена ошибка в отображении таймзоны в PDF-отчете, также в отчет было добавлено немного полезной информации о vSAN
Установка testname и testcase как переменных фреймворка Grafana
Добавлена информация о CPU workload на страницу конфигурации модели fio
Обновлен пакет rbvmomi - теперь он поддерживает vSphere 7.0+
Улучшенные дашборды компонентов fio и vdbench graphite
Скачать HCIBench 2.4 можно по этой ссылке. Документация доступна тут.
Те из вас, кто следит за анонсами Apple, наверняка знают, что компания решила отказаться от процессоров Intel в новом поколении компьютеров Mac, включая MacBook. Процессоры, разработанные компанией Apple, будут созданы на базе ARM-архитектуры, которая откроет возможности по увеличению производительности, уменьшению использования батареи и перспективы совместимости приложений между устройствами Apple других форм-факторов (телефоны и планшеты) без каких-либо изменений со стороны разработчиков. С точки зрения ОС, это все будет имплементировано в следующем поколении операционных систем, начиная с macOS Big Sur.
Но для нас в этой новости главное вот что - из-за смены архитектуры Intel на собственную ARM-платформу Apple перестанут работать решения для виртуализации настольных ПК VMware Fusion и Parallels Desktop, обеспечивающие работу виртуальных машин с гостевыми ОС Windows.
Не секрет, что пользователи Mac и MacBook все меньше и меньше пользуются Windows в ежедневной работе, ну а такой переход, возможно, и вовсе принудительно отменит ставшую уже небольшой необходимость.
В новой ОС для маков будет присутствовать решение по трансляции кода Rosetta 2, которое будет обеспечивать работоспособность x86/x64-приложений на базе архитектуры Apple. Но - за исключением платформ виртуализации VMware и Parallels, которые используют довольно много расширенных возможностей процессоров Intel.
Кроме того, не будет работать и механизм двойной загрузки операционной системы Boot Camp.
Понятное дело, что ситуация эта, скорее всего, временная - VMware и Parallels наверняка уже работают над решением этой проблемы и разработкой собственных платформ для новой архитектуры. Но очевидно, что дело это довольно долгое, а Apple, скорее всего, прорабатывает этот вопрос уже давно и выкатит собственное решение довольно быстро.
Таги: VMware, Apple, Fusion, Parallels, Desktop, CPU
Многие из вас знают, что в решении для организации отказоустойчивых кластеров хранилищ VMware vSAN есть функции дедупликации и сжатия данных (deduplication and compression, DD&C). С помощью этих функций можно более эффективно использовать ярус хранения данных виртуальных машин (Capacity Tier). О некоторых аспектах применения дедупликации и сжатия данных в vSAN мы рассказывали вот тут, а сегодня поговорим об их общем влиянии на производительность дисковой подсистемы.
Как знают администраторы vSAN, это решение использует двухъярусную архитектуру, создающую оптимальное соотношение цена/качество для хранилищ ВМ - на Cache Tier, собранном из дорогих SSD-дисков (быстро работающих на дисках), размещается Write Buffer и Read Cache, а на дешевых SSD/HDD-дисках - постоянные данные виртуальных машин.
Механизм DD&C работает так - если он включен, то как только из Cache Tier виртуальной машине отправляется квитанция о записи данных, то может начаться процесс дестейджинга данных на Capacity Tier, во время которого сам механизм и вступает в действие. Сначала с помощью механики дедупликации в рамках дисковой группы (deduplication domain) находятся идентичные блоки размером 4 КБ и дедуплицируются, а затем блоки сжимаются. При этом, если блок сжимается менее, чем на 50%, то целевое хранилище записывается оригинал блока в целях быстрого доступа при чтении (без декомпрессии).
Получается, что механизм DD&C - оппортунистический, то есть он работает не всегда, а по мере возможности и не гарантирует конкретных результатов по эффективности сжатия данных на целевом хранилище.
Такая модель позволяет не затрагивать процесс посылки квитанции виртуальной машине о записи данных, а также не заморачиваться с дедупликацией блоков уже на целевом хранилище в рамках пост-процессинга.
Очевидно, что дедупликация с компрессией могут влиять на производительность, так как требуют ресурсов процессора на обработку потока ввода-вывода. Давайте посмотрим, как именно.
При высоком входящем потоке операций чтения и записи vSAN старается обеспечить наименьшую задержку (latency) при прохождении команд. При этом vSAN сам решает, в какой именно момент начать процесс дестейджинга данных, поэтому буфер на запись заполняется разные моменты по-разному.
Такая двухъярусная система vSAN имеет 2 теоретических максимума:
Max burst rate - возможность Cache Tier сбрасывать обработанные пакеты данных в сторону Capacity Tier
Max steady state rate - установившаяся максимальная скорость записи данных на приемнике Capacity Tier
Реальная скорость обмена данными между ярусами лежит где-то между этими значениями. Если вы будете использовать бенчмарк HCIBench на длительном отрезке времени, то сможете практическим путем определить эти значения из соответствующих графиков замера производительности хранилища.
Если у вас идет дестейджинг данных с включенным DD&C, это потенциально может повлиять на производительность записи данных на Capacity Tier. При использовании DD&C снижается максимальная скорость записи данных на ярус постоянного хранения, так как перед этой записью должны быть выполнены операции дедупликации и сжатия.
Иными словами, кластер с включенным DD&C может давать такие же показатели качества обслуживания, как и кластер с более медленными устройствами в Capacity Tier, но с выключенным DD&C.
Логично ожидать, что при включенном DD&C буффер Write Buffer будет заполняться скорее, так как будут возникать задержки ожидания отработки DD&C. Но пока буффер полностью не заполнен - заметных просадок в производительности не будет. Очищаться также Write Buffer будет медленнее при включенном DD&C.
Также может измениться и время отсылки квитанции о записи (acknowledgment time, оно же write latency), которое увеличит latency для виртуальной машины. Это произойдет, если уже начался дестейджинг данных, а машина запрашивает ACK и ждет ответа с уровня буффера. Хотя в целом vSAN построен таким образом, чтобы как можно быстрее такой ответ дать.
Надо отметить, что vSAN не торопится сразу скинуть все данные из Write Buffer на диск. В vSAN есть интеллектуальные алгоритмы, которые позволяют делать это равномерно и вовремя, с учетом общей текущей нагрузки. Например, при частой перезаписи данных одной ячейки памяти, она обрабатывается в цепочке сначала именно на уровне буффера, а на диск уже идет финальный результат.
Если вы также используете RAID 5/6 для кластеров vSAN, то совместно с техниками DD&C могут возникнуть серьезные эффекты с влиянием на производительность. Об этих аспектах подробно рассказано вот тут - обязательно ознакомьтесь с ними (см. также комментарий к статье).
По итогу можно сделать следующие выводы из этой схемы:
Если вам хочется использовать DD&C, и вы видите, что у ВМ высокая latency - попробуйте более быстрые диски на Capacity Tier.
Используйте больше дисковых групп, так как Buffer и его пространство hot working set используется на уровне дисковой группы. Две группы на хосте нужно минимум, а лучше три.
Альтернативой DD&C могут стать устройства большой емкости - там просто все поместится).
Используйте последнюю версию vSAN - алгоритмы работы с данными все время совершенствуются.
Также помните, что RAID 5/6 также экономит место по сравнению с RAID1, что может стать альтернативой DD&C.
Ну и главный вывод он как всегда один: производительность - это всегда компромисс между требованиями рабочих нагрузок и деньгами, которые вы готовы потратить на обеспечение этих требований.
Некоторым администраторам может понадобиться PowerCLI-сценарий, с помощью которого можно подсчитать число гостевых операционных систем в виртуальных машинах инфраструктуры VMware vSphere. Stuart в своем блоге рассказал про интересный скрипт, с помощью которого это можно сделать.
Начал он с того, что в переменную $server2012 он записал количество гостевых операционных систем определенного типа с помощью команды:
$server2012 = ((get-vm).extensiondata.guest | Where GuestFullName -eq "Microsoft Windows Server 2012 (64-bit)").count
Далее он стал думать, как сделать таблицу со всеми ОС, для этого решил создать хэш-таблицу, куда будут записываться типы гостевых ОС и их количество:
После этого он сделал скрипт, который собирает в таблицу типы гостевых ОС и увеличивает счетчик, если они встречаются среди виртуальных машин снова при прогоне цикла:
В этой таблице все в порядке, кроме последней строчки - в нее набиваются гостевые ОС, для которых тип не был обнаружен. Поэтому автор добавил следующие строчки с именами ВМ, чтобы добавить значение Unknown таким машинам:
# Added this to the beginning of the script
$NullOS = Get-Content C:\Scripts\Logs\Guestfullname.txt
# Added this to the foreach loop section
IF ($OSName -eq $NullOS){$OSName = "Unknown"}
Компания VMware выпустила на днях обновление одного из самых главных своих документов - "Performance Best Practices for VMware vSphere 7.0". Мы не зря в заголовке назвали это книгой, так как данный документ представляет собой всеобъемлющее руководство, где рассматриваются все аспекты поддержания и повышения производительности новой версии платформы VMware vSphere 7.0 и виртуальных машин в контексте ее основных возможностей.
На 96 листах очень подробно описаны лучшие практики для администраторов платформы и гостевых ОС:
Вот все корневые разделы этого руководства:
Persistent memory (PMem), including using PMem with NUMA and vNUMA
Getting the best performance from NVMe and NVME-oF storage
AMD EPYC processor NUMA settings
Distributed Resource Scheduler (DRS) 2.0
Automatic space reclamation (UNMAP)
Host-Wide performance tuning (aka, “dense mode”)
Power management settings
Hardware-assisted virtualization
Storage hardware considerations
Network hardware considerations
Memory page sharing
Getting the best performance from iSCSI and NFS storage
Для администраторов больших инфраструктур, активно внедряющих новые технологии (например, хранилища с Persistent Memory или DRS 2.0), появилось много всего нового и интересного, поэтому с книжкой нужно хотя бы ознакомиться по диагонали, останавливаясь на новых функциях ESXi 7 и vCenter 7.
Скачать PDF-версию "Performance Best Practices for VMware vSphere 7.0" можно по этой ссылке.
На сайте проекта VMware Labs появилась еще пара интересных обновлений.
Первое - новая версия FlowGate 1.1. Эта утилита представляет собой средство для агрегации данных из различных источников. Это middleware, которое позволяет провести агрегацию данных систем инвентаризации датацентров DCIM / CMDB и далее передать их в системы управления задачами инфраструктуры (например, vRealize Operations). Напомним, что о прошлой версии этого средства мы писали вот тут.
Что нового в обновлении FlowGate 1.1:
Переработаны адаптеры powerIQ и Nlyte - теперь они поддерживают больше метрик и свойств
Доработан Metric API
Улучшена функциональность ручного маппинга, включая поддержку PDU, коммутаторов и сенсоров
Второе - обновилось решение VMware OS Optimization Tool до версии b1160 от 2 июня 2020 года. Напомним, что о прошлой его версии мы писали вот тут.
Это средство предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.
Давайте посмотрим, что нового появилось в июньском апдейте OS Optimization Tool:
Windows Update - новая опция, которая называется Update, позволяющая заново включить функционал Windows Update, который был ранее отключен в рамках оптимизации
Полностью переработанный интерфейс, позволяющий проще изменять настройки и кастомизировать файл ответов
Добавлены команды, с помощью которых можно отключить службы App Volumes, если они установлены, перед запуском шагов стадии Finalize
Выбор опций стадии Finalize теперь сохраняется между прогонами утилиты, что позволяет не терять время на выставление настроек заново
Стандартизация опций командной строки (теперь можно использовать -optimize или -o и т.п.)
Удалены оптимизации, которые будучи не выбраны по умолчанию, могли приводить к проблемам. Например, Disable Scheduled Tasks и CacheTask
Обновлено руководство VMware Operating System Optimization Tool Guide
Скачать VMware OS Optimization Tool b1160 можно по этой ссылке.
Недавно компания VMware выпустила интересный документ, объясняющий иногда возникающие проблемы с производительностью операций чтения с NFS-хранилищ для серверов VMware ESXi версий 6.x и 7.x. В документе "ESXi NFS Read Performance: TCP Interaction between Slow Start and Delayed Acknowledgement" рассматривается ситуация с эффектом Slow Start и Delayed Acknowledgement.
Этот эффект возникает в некоторых сценариях с низким процентом потери пакетов (packet loss), когда используется fast retransmit на передатчике и selective acknowledgement (SACK) на приемнике. Для некоторых реализаций стека TCP/IP в случаях, когда передатчик входит в состояние slow start при включенной отложенной квитанции приема пакетов (delayed ACK), квитанция о приеме первого сегмента slow start может быть отложена на время до 100 миллисекунд. Этого оказывается достаточно, чтобы снизить последовательную скорость чтения с NFS-хранилища на величину до 35% (при этом потери пакетов не будут превышать 0.02%).
Более подробно механика возникновения этого эффекта описана в документе. Там же рассказывается и метод борьбы с этим: если вы подозреваете, что у вас подобная проблема, надо просто отключить ESXi NFS Client Delayed ACK и посмотреть, стало ли лучше. Для этого в консоли нужно выполнить следующую команду:
esxcli system settings advanced set -o "/SunRPC/SetNoDelayedAck" -i 1
После этого убеждаемся, что настройка установлена:
esxcli system settings advanced list | grep -A10 /SunRPC/SetNoDelayedAck
Более подробно об этом можно также почитать в KB 59548.
После этого нужно снова провести тесты на последовательное чтение. Если не помогло, то лучше вернуть настройку назад, указав в качестве параметра первой команды -i 0.
В начале апреля компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью командных сценариев PowerShell до версии PowerCLI 12.0. Напомним, что прошлая версия PowerCLI 11.5 вышла осенью прошлого года.
Давайте посмотрим, что нового появилось в двенадцатой версии фреймворка:
Добавлены командлеты для управления хостовой сетью ESXi
Еще в vSphere 6.0 появилась поддержка сетевых стеков хостов ESXi. Она позволяет назначить различные шлюзы для адаптеров VMkernel в целях маршрутизации трафика. Через PowerCLI можно использовать ESXCLI или API для управления этой функциональностью с помощью командлетов Get-VMHostNetworkStack и Set-VMHostNetworkStack. Новый параметр называется "NetworkStack", он был добавлен в командлет New-VMHostNetworkAdapter:
Добавлены командлеты для управления решением HCX
Появились новые командлеты для управления пространствами имен
Командлеты для управления службами Trusted Host Services
Командлеты для управления диском гостевой ОС виртуальных машин (VM Guest Disk management)
Теперь раздел гостевой ОС можно замапить на VMDK-диск (пока только для Windows-систем). Для этого потребуется vSphere 7 и VMware Tools не ниже 11-й версии. Эту возможность можно использовать с помощью командлета Get-VMGuestDisk:
Новые командлеты для управления VMware Cloud on AWS
Новые командлеты для vSAN:
Get-VsanFileServiceDomain
New-VsanFileServiceDomain
Set-VsanFileServiceDomain
Remove-VsanFileServiceDomain
New-VsanFileServiceIpConfig
Get-VsanFileShare
New-VsanFileShare
Set-VsanFileShare
Remove-VsanFileShare
New-VsanFileShareNetworkPermission
Add-VsanFileServiceOvf
Get-VsanFileServiceOvfInfo
Новый модуль для управления службами VMware Cloud Services
Добавлена поддержка vSphere 7.0
Добавлена поддержка vRealize Operations 8.0
Обновлена поддержка модулей License и vROps, а также командлета Open-VMConsoleWindow для использования на различных платформах
Поддержка Move-VM для сетей opaque networks
Добавлена поддержка последних обновлений PowerShell 7.0:
Скачать VMware PowerCLI 12.0 можно по этой ссылке. Полезные ресурсы:
RSS
